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AMENDMENTS TO THE SPECIFICATION 



Applicant respectfully requests the following changes be made to the specification. The 
following amendments correct typographical errors and render the application's internal cross 
references consistent including references to Figures 6B, 7B, 14A and 17 as amended (see 
below). 

Please replace the paragraph beginning at Page 8, Line 19 with the following paragraph: 
FIGURE 2B FIGURE 4 C is a flow chart showing steps associated with the call control 
engine of FIGURE 2 A processing a service request, or call fi-om the PSTN to the IP network of 
the communication network of FIGURE 1; 

Please replace the paragraph beginning at Page 12, Line 28 with the following paragraph: 
Communication network 10 operates as follows: A service request, or call, originates at 
PSTN 12. Signaling associated with the call, which in this embodiment is according to the SS7 
protocol, travels to signaling gateway 16, as denoted by reference numeral 20. Call routing and 
signaling system 16 receives the SS7 signaling, converts the signaling into an internal format, 
processes the calls, and generates SIP signaling, as denoted by reference numeral 22, for 
transmission to IP network 14. The content of the call travel over public switch telephone lines 
24 through media gateway 18 and over line 26, now according to IP for termination within 
Internet Int e rnal Protocol network 14. Calls originating from IP network 14 are handled in a 
converse manner matt e r . Wireless calls may also be received by call routing and signaling 
system 16, which may convert the signaling into an internal format, process the calls, and 
generate signaling for transmission to either IP network 14 or PSTN 12. 

Please replace the paragraph begiiming at Page 13, Line 28 with the following paragraph: 
InteUigence engine 36 performs functions related to call control. Intelligence engine 36 
determines what route the call will take, and in doing so, also conununicates with database 40 
over line 43 lin e 4 2 . Intelligence engine 36 is described in greater detail below in conjunction 
with FIGURES 16-19. 

Please replace the paragraph begiiming at Page 14, Line 4 with the following paragraph: 
FIGURE 2B is a block diagram of database 40 shown in FIGURE 2 A, These tables 
include a trunk t ruek attribute table 42, a subscriber translation table 44, a SIP proxy routing 



Applicant : Kaczmarczyk 
Serial No. : 09/821,507 
Filed : March 29, 2001 



Attorney Docket No.: SNS-009 
(65672/019) 
Page 3 of 16 



table 46, a calling address attribute table 48, a dialed digits analysis table 50, a local dial plan 
table 52, a calling address privilege table 54, an outbound privacy table 56, a route plan table 58, 
an error table 60, and a local route table 62. Examples of each of these tables are provided below 
in tables 1 through 9 and 1 1, and are described below in conjunction with FIGURES 5 A through 
15. These tables point to additional tables that are not explicitly shown in FIGURE 2B. For 
example, route plan table 58 points to many route tables (as described in greater detail below), 
including, for example, TABLE 10: LD InterLATA Table. 

Please replace the paragraph beginning at Page 16, Line 1 with the following paragraph: 
FIGURE 4A is a flow chart showing additional details of steps associated with call 
control engine 34 processing a service request or call, from PSTN 12 to IP network 14. The 
process begins at step 78 where a translated SIP message is received by call control engine 34 
from signaling agent 30, as denoted by reference numeral 79. Generally, call control engine 34 
creates an instance of a calling address profile, indicated by reference numeral 82, for each 
service request received. A calling address profile is comprised of data defining the call type, 
with associated call attributes, the clients call privileges, and the final routing information to be 
used to determine the call. An example of a calling address profile 82 is calling address profile 
166 in FIGURE 5B. Call control engine 34 generates respective portions of caUing address 
profile 82 by screening the calling address number (step 80), screening the called address (step 
84), screening access privileges (step 92), and routed/intelligence engine 36 determining the call 
routing (step 94) and selecting an appropriate circuit (step St^ 98). Each portion of calling 
address profile 82 generated by each of these steps is available for use in the subsequent step as 
shown generally in FIGURE 4A by the reference numerals 80, 84. 92, 94, and 98 num e rals 81, 
86, 88, 90, and 96 . Calling address profile 82 is used at the end of this process to create and send 
outbound messages. 

Please replace the paragraph beginning at Page 19, Line 19 with the following paragraph: 
FIGURE 4B is a flow chart showing additional details of steps associated with call 
control engine 34 processing a service request, or calls from EP network 14 to PSTN 12 n e tw^ork 
to PSTN 1 4. The method begins at step 394 where signaling agent 30 provides a translated SS7 
message to control engine 34, as denoted by reference numeral 396. Generally, call control 
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engine 34 identifies the called party (rather than calling address), call type and attributes, and 
determining the destination at which the call should terminate. This process is described below. 
At step 398, call control engine 34 performs trunk screening. Call control engine 34 creates an 
instance of a called party profile (not explicitly shown) for each service request received. This is 
in contrast to calling address profile 82 created for calls originating in PSTN 12. As with the 
calling address profile 82, a called party profile is comprised of data defining the call type and 
call attributes, such as call type and call attributes 88, called party call privileges, and the final 
routing information to be used to terminate the call. Therefore, call control engine 34 accesses 
tables based upon the called number that define the called party's destination, privileges, and 
special routing instructions. 

Please replace the paragraph beginning at Page 20, Line 19 with the following paragraph: 
On completion of trunk screening, call control engine 34 identifies call type at step 400 of 
trunk screening. Trunk screening at step 398 st e p 98 provides an index for subscriber translation 
table 44 for the incoming trunk identification in trunk attribute table 42. When call control 
engine 34 accesses subscriber translation 44 table, if an SIP URL, DP address or e-mail address is 
associated with the number, this specifies that the termination is an SIP termination. However, if 
there is no SIP URL, IP URL IP address, or e-mail address, this specifies that the termination is a 
non-SEP termination. 

Please replace the paragraph beginning at Page 20, Line 26 with the following paragraph: 
Step 400 St e p 100 of subscriber translation generates a call type 88. Based on call type 
88, trunk profile 399 profil e 99 , and the original translated SS7 message, call control engine 34 
performs access privilege screening in an analogous manner as the access privilege screening of 
step 92, described above in conjunction with FIGURE 4A. 

Please replace the paragraph beginning at Page 20, line 30 with the following paragraph: 
At a step 406, call control engine 34 routes the call. To do so, remaining data necessary 
to create and route an SIP message are assembled at step 406. This includes identifying the 
destination proxy. To accomplish this task, call control engine 34 determines the called party's 
domain name fi'om the SIP address. The domain name is then used as a key in accessing SIP 
proxy routing table 46. SIP proxy routing table 46 dictates which proxy is used to terminate the 
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call. SIP proxy routing table 46 also allows user 39 to assign several NPA-NXXs to one CMS. 
The process concludes at step 408 step 108 . 

Please replace the paragraph beginning at Page 21, Line 7 with the following paragraph: 
In this example, a caller calls from IP network 14 IP network 12 to a destination in PSTN 
12. In this example, the called number is simply "0", indicating an operator. 

Please replace the paragraph beginning at Page 22, Line 5 with the following paragraph: 
Treatment index 1 18 is a pointer to error table 60. Error table 60 is used to decide what 
type of treatment to use based on a particular error condition and the calling address. PIC 120 is 
the calling party's long distance carrier ID code. LPIC 122 is the calling party's local service 
provider carrier ID code and is used as a key to route Ust table 162, as denoted by reference 
numeral 148.[[.]] LPIC 122 is provided in this example to local route table 162 tabl e 62 as 
indicated by reference numeral 148, JIP 124 refers to jurisdiction information and identifies the 
switch from which the call originates and can be recorded to identify that switch. II 126 
identifies the originating line. For example, if the calling party is calling from a prison phone, 
pay phone or regular phone. 

Please replace the paragraph begirming at Page 23, Line 3 with the following paragraph: 
At step 158, call control engine 34 screens privileges to determine if the particular call 
type 88 is allowed. In this example, the call type 88 is a local operator call without digits. 
Calling address privilege index 114 identifies a calling address privilege table 54 tabl e 15 4, 
which specifies that the only restrictions on the calling party are 976 numbers; therefore, the call 
type is allowed. 

Please replace the paragraph beginning at Page 25, Line 29 with the following paragraph: 
FIGURE 9 are schematic diagrams showing tables and steps associated with processing a 
premium services access code request. FIGURES 9A and 9B illustrate an example of call 
process for a premium service access code call such as "900-333-1212." Based on the called 
digits "900," call control engine 34 then determines from dialed digits analysis 50 at step 226 
that the call type 88 is a premium service access code call, as illustrated by reference numeral 
238 num e ral 228 . Call control engine 34 uses this call type 88 to identify within route plan table 
58 a route list table 230, which in this case has a title "Premium SAC Route Table." Route hst 
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table 230 specifies a route set 232 having a title in this case of "premium SAC route set." Route 
set 232 is provided to provided is resource manager 28 as denoted by reference numeral 234. 
Resource manager 28 determines the appropriate circuit for completing the call, as denoted by 
reference numeral 236, and processing proceeds as described above. 

Please replace the paragraph beginning at Page 26, Line 23 with the following paragraph: 
FIGURE 1 1 are schematic diagrams showing tables and steps associated with processing 
an intemational operator with digits dialed request. FIGURES 1 1 A and B show call processing 
for an intemational operator with digits call, such as for example, "0144334561234." Based on 
the dialed digit "0" call control engine 34 determines that the call type 88 is an operator with 
digits call. This is indicated by reference numeral 250. Based on the next two digits "01" call 
control engine 34 determines that the call type 88 is additionally an intemational operator call 
with digits. This is indicated by reference numeral 252. The next eleven digits "44334561234" 
are used when the call is routed to the operator, as designated by reference numeral 254 num e ral 
344. Based upon these call type and attributes 88, call control engine 34 determines from route 
plan table 58 an appropriate list table 256, which in turn in t e m specifies an appropriate route set 
258. Route set 258 is provided to resource manager 28 as indicated by reference numeral 260, 
and resource manager 28 selects an s e lects and appropriate circuit, as noted by reference numeral 
262. Call processing from this point points continues as described above. 

Please replace the paragraph beginning at Page 28, Line 10 with the following paragraph: 
FIGURE 1 5 are schematic diagrams showing tables and steps associated with processing 
an error calling address not found request. FIGURE 15 FIGURE 15A illustrates call processing 
for an error condition in which the calling address is not found. In this example, the calling 
address that is [[says]] not found is "972-931-3000." At step 288, call control engine 34 does not 
find the calling address attribute table 48; therefore error processing is invoked at step 288. 
According to this embodiment, call control engine 34 generates an error "U" indicating a calling 
address is not found. In addition, by default, treatment index "7" is specified for a default calling 
address. Based upon error code 290 and treatment index 1 18 an error route list is selected by call 
control engine 34 and the treatment of the call is sent back to the original user at step 394. 

Please replace the paragraph beginning at Page 45, Line 3 with the following paragraph: 
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In one embodiment of the invention, telephony management layer 1722 may access a 
plurality of tables. These tables may reside locally and/or may be accessed directly from a single 
or multiple databases 40. FIGURE 17 illustrates these tables using the terms "tiers" and "levels" 
for generality. For example, facility management command and control layer 1712 lay e r 1702 
may access a plurality of Level One tables, Tiers 1-n. Similarly, telephony management layer 
1722 may access a plurality of Level Two tables, Tiers 1-n, and customer managed layer 1732 
may access a plurality of Level Three tables, Tiers 1-n, to associate billing, accounting and MIS 
data with a call event. For example, distributor 1702 may send a business request 1735 to 
customer managed layer 1732, which may then access one or more of the plurality of Level 
Three tables to associate billing or other data with the call event. Such information may be used 
for a variety of applications, including billing, auditing, and/or accounting related to call events 
to or from a subscriber. Each of Level One, Level Two, and Level Three tables may logically be 
arranged in a hierarchical form, such as illustrated in FIGURE 17. Although FIGURE 17 
illustrates these tables in a hierarchical form, the invention contemplates the use of a variety of 
logical and/or functional configurations for these tables, depending on the application. 

Please replace the paragraph beginning at Page 48, Line 19 with the following paragraph: 
Facility management and control layer call control or logic engine 1713 is operable to 
receive a signal such as a keepalive or watchdog that indicates whether a malfimction, misfire, 
congestion, and other network delays may prevent processing of call events through an element 
such as a media gateway controller. Keep-alive messages typically time out and alert systems 
when an element is malfunctioning misfunotioning or inoperable. Facility management 
command and control layer call control or logic engine 1713 may then reconfigure a signal path 
to be routed from a malfunctional or inoperable call agent 1610a to another control engine 
1610b. Facility management command and control layer call control or logic engine 1713 may 
access dispatch circuit tables, dispatch trunk tables, and dispatch group tables cabl e s , among 
others, to logically reroute a terminating switch to follow an originating switch. Thus, as 
indicated by arrow 1650 arrow 1850 , should media gateway controller 1610b fail, media 
switches 1 822 that are physically controlled thereby may be rerouted by facility management 
command and control layer call control or logic engine 1713 to be logically controlled by media 
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gateway controller 1610a. Thus, call events from media switches 1822b are rerouted to call 
agent 1610a. 



